Implementation wise, manually tested and it works as expected! 💯
Suggestion on the name of the commands -
Could we do something like kedro catalog factories --list and kedro catalog factories --resolve for #2791? IMO kedro catalog factories does not explain what it does enough.
We could even do kedro catalog list --factories for this. Would like to hear what everyone else thinks?

Implementation wise, manually tested and it works as expected! 💯 Suggestion on the name of the commands - Could we do something like kedro catalog factories --list and kedro catalog factories --resolve for #2791? IMO kedro catalog factories does not explain what it does enough. We could even do kedro catalog list --factories for this. Would like to hear what everyone else thinks?

I think this is an interesting point. I tend to agree that kedro catalog factories isn't very self explanatory. It would be good to get @amandakys's designer point of view. We need to ensure this is consistent with the other CLI commands, just like the exercise we did for kedro run and all the flags there.

This new command should also be added to the docs with a short explanation.

I had a look at the existing 'list' style commands and we have:

kedro catalog list - list datasets per pipeline per type

• also has the optional argument --pipelines that allows you to further narrow down the list of datasets returned by pipeline name.

kedro registry list - list all registered pipelines in your project
we also have kedro registry describe which outputs all the nodes in a specified pipeline

As a note here - it could be more intuitive to reduce the number of keywords by changing kedro registry describe to be kedro registry list --pipelines=<pipeline-name> or kedro register list --nodes --pipelines=<pipeline-name>. There is potential for discussion here on our use of arguments, when to use as a input vs as an argument to a --pipeline flag. If there was interest in this work i'd be happy to do an audit

The convention appears to be putting the verb at the end of the command with additional parameters being used to narrow down the output. So initial thoughts would be that kedro catalog factory list is the most consistent.

However, it does depend on whether there are future plans for providing different types of outputs to allow users to better understand their catalog i.e. returning a full 'expanded' catalog, or providing a dataset name and returning which pattern it matched. In this case we could consider the addition of another key word like resolve or adding arguments to the list command like --datasets

quick xref #2402 and #2723

(This is only tangentially related to the current discussion, but adding them since I saw a mention of kedro registry list)

Thanks for the detailed analysis @amandakys ! I think reading this and keeping in mind that we have #2791 coming up I would suggest going for kedro catalog factory list and then the command for #2791 can be kedro catalog factory resolve.

Fixed!
Coverted back to draft as currently only works with kedro catalog "factory list" and not kedro catalog factory list

Still in draft mode as I've got another question for reviewers:

I've refactored test_get_cli_structure_help with two approaches, iterative and recursive. I'm not particularly partial to either method; whilst iteration is faster and more memory-efficient, we are not handling any considerable amounts of data with this test.

Does anyone have any opinions on this?

Also to note - the code that is tested by test_get_cli_structure_help (and the tests themselves) are duplicated in kedro-telemetry which brings two things:

1. Any refactoring decided here should be applied there
2. Why do we have duplicate code? Can it be removed from Kedro framework?

I agree with @noklam that kedro catalog factory list seemed unusually long for me as well. @amandakys point above about consistency is important though 🤔 @noklam do you have any alternatives in mind, taking into account the discussion above?

I agree we should try to limit bikeshedding

In my mind I prefer just kedro catalog list and introduce new arguments - - resolve for the addition functions

Pro:

• consistent with the current command, less intrusive.

Cons:

• May blurred things a bit but I don't think this is too important.

If we are going to change these CLI, it's a breaking change and we cannot add it later. Introducing a new command is not breaking but it is more intrusive we introduce a new one and later reactor it into other commands.

After discussion with @merelcht, @noklam, @amandakys, @ankatiyar, and @astrojuanlu we have decided to implement this functionality under the command kedro catalog rank, and keep #2791 as kedro catalog resolve. As this affects several choices made on this branch, I will be closing this in favour of a new, clean PR.